feat: multi-header auth for VTEX-style APIs#21
Merged
Conversation
Adds --header flag (repeatable) to auth login and at invoke time, so APIs
requiring multiple simultaneous auth headers (e.g. VTEX's X-VTEX-API-AppKey
+ X-VTEX-API-AppToken) work end-to-end. Persists as a "headers" profile type,
resolves $VAR / ${VAR} per value, and --agent-help now hints multi-header
usage when the spec declares two or more apiKey header schemes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
16effd7 to
0a07171
Compare
Previously --verbose only masked Authorization. With multi-header auth, X-VTEX-API-AppKey/Token and any apiKey custom header leaked in plaintext to stderr — would end up in CI logs. Now masks every header added via the auth path using the same maskToken() helper used by `auth status`. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- parseHeaderFlag now rejects CR/LF in name/value (RFC 7230 header injection)
and enforces RFC-valid token chars in header names.
- resolveEnvVar warns to stderr when $VAR resolves to unset or empty —
silent empty headers produce confusing 401s ("auth wrong" when it's "env unset").
- index.ts parseHeaderArgs now delegates to parseHeaderFlag so CLI-time
argv parsing shares the same validation as `auth login`.
- .gitignore: ignore .claude/ harness state.
Addresses code-review feedback on PR #21.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
lucianfialho
added a commit
that referenced
this pull request
Apr 14, 2026
Highlights since v0.5.0: - feat: multi-header auth for VTEX-style APIs (#20, PR #21) - --header / -H flag, repeatable, works inline and via `auth login` profiles - $VAR / ${VAR} expansion per header value with empty-var warning - --agent-help now suggests multi-header usage on specs with 2+ apiKey schemes - fix: mask all auth header values in --verbose output (not just Authorization) - fix: reject CR/LF in header names/values (RFC 7230 injection guard) - fix: parse object and array params from JSON strings (#15, PR #19) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #20.
Summary
--header "Name: Value"(repeatable, also-H) toauth loginand at invoke time"headers"auth type — stored in profiles, sent on every request$VAR/${VAR}resolution per header value (so tokens can come from env)--agent-helpnow emitsmulti-header --header "X-VTEX-API-AppKey: <value>" --header "X-VTEX-API-AppToken: <value>"when the spec declares 2+ apiKey header schemes--dry-runprints every custom header (both plain and curl output)Design choice
Went with Option A from the issue (generic
--headerflags). Rationale: works for VTEX and any future N-header scheme without bespoke flags. Option C (interactive auto-detect fromsecuritySchemes) is deferred — the detection primitive (detectApiKeyHeaders) is in place so a follow-up can add the prompt flow without refactoring.Usage
Test plan
parseHeaderFlag: valid, whitespace,:in value (URL), missing colon, empty namedetectApiKeyHeaders: multi-scheme + emptyresolveAuth: flag-based, env-var expansion, precedence over--token, profile load, empty-object fallthroughexecuteRequest: VTEX-style dual-header sent on the wireauth login -H ... -H ...→auth statusmasks each header--dry-runagainst a synthetic VTEX spec emits both headers + curl--agent-helpon dual-header spec emits correct hint